EC2インスタンス上にActive Directory環境を構築する際のTIPS
みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。
EC2インスタンス上にWindowsの「Active Directory」環境を構築する際のTIPSをいくつかご紹介します。
今回は、以下のような構成を前提に説明します。 (オンプレミスのActive Directoryと連係しておらず、AWS内に閉じたActive Directory環境)
TIPSその1： DNSについて
DNS参照先の設定
Active DirectoryはDNSと密接に連係するサービスです。
Active Directoryのドメインコントローラー、および、ドメインに参加するメンバーサーバー・メンバークライアントは、DNSの参照先を適切に設定する必要があります。
ドメインコントローラーは、自サーバー内にActive Directoryと連係するDNSサービスを持っています。 *1 そのため、ドメインコントローラーとなるサーバーのDNS参照先設定は「自サーバー ＝ localhost (127.0.0.1)」に設定します。
メンバーサーバー・メンバークライアントは、ドメインコントローラーのDNSを参照します。
具体的な各サーバーのDNS設定について詳しく説明します。
1台目のドメインコントローラー (FSMO)
ドメインコントローラーへ昇格する際に、自動的にDNS参照先が「127.0.0.1」に設定されます。
ドメインコントローラー昇格前：
ドメインコントローラー昇格後：
したがって、特に設定を行う必要はありません。 (設定内容の確認は行った方がよろしいかと思います)
2台目以降のドメインコントローラー
ドメインコントローラーへ昇格する前に、一時的に、既存のドメインコントローラーをDNS参照先に指定します。 これは、自分がドメイン内のドメインコントローラーの一員となる過程で、ドメイン名から既存のドメインコントローラーの名前やIPアドレスを解決する必要があるためです。 (下図は、1台目のドメインコントローラーのIPアドレスが「192.168.1.218」であった場合の例です)
ドメインコントローラーへ昇格すると、自動的に「127.0.0.1」が追加されて以下のような状態になります。
これを、手で修正して「127.0.0.1」のみにする必要があります。
メンバーサーバー・メンバークライアント
ドメインへ参加する前に、DNS参照先にドメインコントローラーを指定します。 WindowsのDNS設定は「優先DNSサーバー」「代替DNSサーバー」の2つを設定できますので、複数のドメインコントローラーが存在する場合は、そのうち2つを選んで指定します。(通常は、ネットワーク的に近いものから2つを選択します)
(1台目のドメインコントローラーのIPアドレスが「192.168.1.218」、2台目のドメインコントローラーのIPアドレスが「192.168.2.58」であった場合の例です)
DNSフォワーダーの設定
VPCには「AmazonProvidedDNS」と呼ばれるAWSが提供するDNSが用意されています。 このDNSを参照することにより、以下の名前解決が行える仕組みです。
- EC2インスタンスのプライベートDNS名 (例：
ip-xx-xx-xx-xx.ap-northeast-1.compute.internal) - その他のAWSリソースのプライベートDNS名 (例：
database-1.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com) - インターネットの名前解決 (例：
www.google.co.jp) - AWSリソースのパブリックDNS名も「インターネットの名前解決」に含まれます
EC2インスタンス (Windows/Linux問わず) の初期設定では、DHCPから取得した情報によってDNS参照先が「AmazonProvidedDNS」に設定されます。
ところが、前項での説明の通りにDNS参照先の設定を修正すると、「AmazonProvidedDNS」を参照するという設定が上書きされて消えてしまいます。
Active Directoryのドメインに参加する上ではドメインの名前解決は必須なのですが、一方で、AWSリソースの名前解決やインターネットの名前解決も必要という場合があります。 そのような場合には、DNSの「フォワーダー」という仕組みを使って解決します。
フォワーダーとは、DNSサーバーがクライアントから名前解決の問い合わせを受けた際、自分で名前解決できない要求であった場合に、他のDNSサーバーへ要求を転送する機能です。
ドメインコントローラーのDNSサービスは、ドメインcorp.example.comの名前解決はできますが、それ以外 (例えばap-northeast-1.compute.internalやgoogle.co.jp) の名前解決はできないため、フォワーダーに設定された「AmazonProvidedDNS」に対して名前解決の要求を転送します。
フォワーダーの設定方法
ドメインコントローラーで「DNSマネージャー」を起動して、DNSサーバーのプロパティを開きます。
「フォワーダー」タブを選択して、設定されている内容を確認します。
「AmazonProvidedDNS」のIPアドレスは、VPCのCIDRブロックの最初のアドレスに「2」を足したものです。 (例えば、VPCのCIDRブロックが「192.168.0.0/16」である場合、「AmazonProvidedDNS」のIPアドレスは「192.168.0.2」となります)
フォワーダーに「AmazonProvidedDNS」のIPアドレスが設定されている場合は、そのまま何もしなくてOKです。
異なるIPアドレスが設定されていたり、何も設定されていない場合は、「編集」をクリックして設定を修正します。
これを、全てのドメインコントローラーで確認・設定します。
(参考) Bad Practice
間違えやすい点として、Active Directoryドメインの名前解決と「AmazonProvidedDNS」による名前解決のどちらも行いたいからと言って、以下のように設定してしまうことです。
- 優先DNSサーバー： Active DirectoryのDNS
- 代替DNSサーバー： AmazonProvidedDNS
このような設定を行っても 期待通りに動作しません。
WindowsのDNS設定における「優先DNSサーバー」と「代替DNSサーバー」の関係は、「優先DNSサーバーで名前解決できなかったエントリーを代替DNSサーバーへ問い合わせる」という動きではなく、「優先DNSサーバーが通信不可などで使えない場合に、代替DNSサーバーを使って名前解決を行う」であるためです。
ドメインサフィックス検索の設定
「ドメインサフィックス検索」とは、DNSへ名前解決の問い合わせを行う際に、FQDN (例：sv01.corp.example.com) ではなくホスト名のみ (例：sv01) で指定した場合に自動的にドメイン名部分 (＝DNSサフィックス) を追加してから名前解決を試みてくれる機能です。
EC2でWindowsインスタンスを起動すると、デフォルトでは「ドメインサフィックス検索」が下図のように設定されます。
デフォルトでは「以下のDNSサフィックスを順に追加する」が選択されており、DNSサフィックスにはAWSリソースのドメイン名であるap-northeast-1.ec2-utilities.amazonaws.comやap-northeast-1.compute.internalが登録されています。
Active Directoryドメインのドメインコントローラーやメンバーサーバー・メンバークライアントになる場合、「プライマリおよび接続専用のDNSサフィックスを追加する」を選択する必要があります。
この変更により、AWSリソースの名前解決を行う際にホスト名のみでの名前解決ができなくなる点に留意する必要があります。
(FQDNで問い合わせた場合は問題なく名前解決できるため、大きな問題は無いかと思います)
TIPSその2： 時刻同期について
Active Directoryで採用されている「Kerberos」プロトコルは、機器間での正確な時刻同期が求められるプロトコルです。 そのため、ドメインコントローラーやメンバーサーバー・メンバークライアントで時刻同期サービス「Windows Time Service」(W32Time) の設定を適切に行う必要があります。
Active Directory環境での時刻同期の構成は下図のようになります。
各ドメインコントローラーはW32Timeのサーバー兼クライアントとして動作し、上位のタイムサーバーに対して時刻同期を行い、メンバーサーバー・メンバークライアントに対して時刻同期を提供します。
1台目に構築したドメインコントローラーは、正確な時刻を提供するタイムソース (NTPサーバー) から時刻を受け取り、ドメイン内で最上位のタイムサーバーとして動作します。 *2
AWSでは、VPC内で利用できるNTPサーバーとして「Amazon Time Sync Service」(IPアドレス：169.254.169.123) が提供されているため、これを利用します。
2台目以降に構築したドメインコントローラーは、1台目のドメインコントローラーに対して時刻同期を行います。 (1台目のドメインコントローラーから時刻を受け取れない場合は、他のドメインコントローラーに対して時刻同期を行う場合もあります)
メンバーサーバー・メンバークライアントはW32Timeのクライアントとして動作し、ドメインコントローラーのいずれかに対して時刻同期を行います。
時刻同期の設定方法
Windowsでは、ドメインコントローラーへの昇格やドメインへの参加によって、W32Timeの以下のような設定が適切に行われるようになっています。
- W32Timeのサーバーとして動作するか、クライアントとして動作するか
- 時刻同期の参照先
- 時刻同期の周期、時刻の「ずれ」に対する補正方法、etc.
したがって、基本的には特に設定を行う必要は無いのですが、AWSのVPC環境では一部の設定を修正する必要があります。
(例えば、時刻同期の参照先にtime.windows.comが追加設定されてしまう等)
1台目のドメインコントローラー
コマンドプロンプトから以下を実行して、設定を行います。
> w32tm /config /manualpeerlist:"169.254.169.123,0x9" /syncfromflags:manual /reliable:yes /update > net stop w32time > net start w32time
w32tmコマンドのオプション/manualpeerlist:"169.254.169.123,0x9"および/syncfromflags:manualによって、タイムソースを「Amazon Time Sync Service」に指定しています。
また、/reliable:yesによって自身を「権威のあるタイムサーバー」(最上位のタイムサーバー) であると宣言しています。
W32Timeの設定変更後、W32Timeサービスを再起動して設定を反映します。
設定変更後、以下のコマンドによって設定が適切に反映されたことを確認します。
> w32tm /query /configuration (以下、結果抜粋) AnnounceFlags: 5 →「権威のあるタイムサーバー」として動作している NtpClient Enabled: 1 → W32Timeクライアントとして動作している Type: NTP NtpServer: 169.254.169.123,0x9 → 時刻同期の参照先が「Amazon Time Sync Service」に設定されている NtpServer Enabled: 1 → W32Timeサーバーとして動作している
2台目以降のドメインコントローラー
以下のコマンドを実行して、設定を行います。
> w32tm /config /manualpeerlist:"169.254.169.123,0x9" /syncfromflags:domhier /update > net stop w32time > net start w32time
w32tmコマンドのオプション/syncfromflags:domhierによって、ドメイン内のドメインコントローラーに対して時刻同期を行うように設定しています。
(/manualpeerlist:"169.254.169.123,0x9"の指定は本来不要ですが、time.windows.comの設定を消去するために敢えて指定しています)
設定変更後、以下のコマンドによって設定が適切に反映されたことを確認します。
> w32tm /query /configuration (以下、結果抜粋) NtpClient Enabled: 1 → W32Timeクライアントとして動作している Type: NT5DS → 時刻同期の参照先が「ドメイン内のドメインコントローラー」に設定されている NtpServer Enabled: 1 → W32Timeサーバーとして動作している
メンバーサーバー・メンバークライアント
以下のコマンドを実行して、設定を行います。
> w32tm /config /manualpeerlist:"169.254.169.123,0x9" /syncfromflags:domhier /update > net stop w32time > net start w32time
設定内容は「2台目のドメインコントローラー」と全く同じです。
設定変更後、以下のコマンドによって設定が適切に反映されたことを確認します。
> w32tm /query /configuration (以下、結果抜粋) NtpClient Enabled: 1 → W32Timeクライアントとして動作している Type: NT5DS → 時刻同期の参照先が「ドメイン内のドメインコントローラー」に設定されている NtpServer Enabled: 0 → W32Timeサーバーとしては動作していない
おわりに
主に「あまりWindowsやActive Directoryになじみが無い」「オンプレミスではActive Directoryを構築したことはあるが、AWSでは構築したことがない」といった方に向けて、ポイントとなる点をご紹介しました。
オンプレミスのActive Directoryと連係する場合のTIPSなどについては、またの機会にご紹介できればと思います。
